The present invention generally relates to software debugging technology, particularly to a method and system for invoking Just-In-Time (JIT) debugger, in which a corresponding JIT debugger is selected for a code-mixed application.
The rising complexity of software system brings more and more bugs that can't be reproduced or occur only occasionally. The context of the program is unavailable if a debugger is started at that moment to debug that program. Thus traditional debuggers can do little on these bugs. JIT (Just-In-Time, JIT) debugging is proposed to address the above problem. JIT (Just-In-Time) debugging is a technique that a debugger could be invoked automatically when bugs mentioned above occur. It has been an integral part of modern debugging.
So far, some methods or systems have been designed to provide support for the JIT debugging, for example, JIT debugging through exception hook and JIT debugging through OS-specific exception have been proposed. However, there is no specific support provided in existing technologies for code-mixed applications.
“Code-mixed Applications” are used to denote some applications that are deployed in one native code and/or one or several non-native codes, often developed in more than one language. Generally, different modules of an application can be written in different programming languages, and compiled into the different code types.
Native codes or non-native codes have no inherent relationship with programming languages. For example, Java programs are often compiled into Java byte codes, which are non-native codes. However, Java programs could also be compiled into native codes by GCJ, or GNU Compiler for Java.
There are great differences between native codes and non-native codes. From the perspective of debugging, debuggers will use different methods to control the execution of debugging of different codes. For example, the breakpoint instruction is 0xCC for all native codes on IA32 platform, while the breakpoint instruction is 0xCA for Java byte codes, non-native codes, on Java Virtual Machine.
Most of the time, mixed code will probably exist in an application because there is typically not any one type of code that meets all requirements. Each code type has its own advantages in different business fields; for example, the non native code may be more portable while the native code is more efficient. Nowadays, more and more large applications tend to be code-mixed, such as Lotus Notes, especially with the prevalence of the Java language.
Existing methods do not provide any specific support for code-mixed applications. Only a predefined debugger can be started in the existing methods when there is a need to start JIT debugging. However, the incorrect debugger may be started for code-mixed applications in the existing methods.
FIG. 1 illustrates the existing JIT debugging process for a code-mixed application. As shown in FIG. 1, when a process i triggers JIT debugging in operation s101, it is unknown which debugger should be started. Therefore, the JIT debugger configured in advances is invoked in operation S102 and debugging is attempted in operation s103. Supposing that process i was a process in AIX operating system, comprising thread 1 in C language and thread 2 in Java language, if dbx (a C language debugger) is configured as a JIT debugger, the dbx will be invoked in any circumstance which requires JIT debugging. However, the dbx would not be much help if the codes triggering JIT debugging are located at Java Byte Code (thread 2), because dbx cannot provide JIT debugging support for Java non native code. Conversely, if jdb (a java debugger) is configured as the JIT debugger, it is also unable to do much work if the JIT debugging is from native codes (thread 1).
When traditional JIT debugging support is used for code-mixed applications, there are at least the following two problems:
1) It will cost much if JIT debugging support is implemented in all interpreters for all non native code, such as Java, C# MSIL code, etc. And with the emergence of new non native code, all of the respective interpreters are needed to be modified to provide JIT debugging support for these kinds of non native codes. So it is not feasible to use traditional ideas from business perspective.
2) It is difficult to establish a mapping relationship between operating system events and non-native code events. Once one application, especially a code-mixed application, becomes bigger and bigger, the performance tuning will be one inevitable issue. For most performance analyzers, they need to know what code, native code or non-native code, is being executed when something, such as frequent memory page swapping in operating system, happens. The traditional manner of JIT support, which often tends to be implemented within the interpreters, can't meet this requirement because there is no way for the interpreter to catch operating system low-level events.
Therefore, there is a need to provide a method and system for invoking Just-In-Time debugger, which can provide more efficient JIT debugging for the complex code-mixed application. Such method and system may not only solve the problem that existing method cannot satisfy the JIT debugging requirement for code-mixed applications, but may also overcome the two problems involved with code mixed applications.